关于优惠券功能设计之我的见解

0x01

一些网站或APP在为了吸引用户，会在一些特定时间推出一些优惠券，然后用户通过认领这些优惠券从而在购买指定商品中获取到一些优惠。

0x02

根据此业务估计熟悉关系型数据库设计的人，脑海里立马就能想出下面3张表

1. 用户表

2. 优惠券表

3. 用户优惠券认领表

假设所有的用户都认领了每次发放的优惠券那么：
用户优惠券认领表 = 用户记录 × 优惠券记录
如果用户数为：1000 ，优惠券为：100，那么用户优惠券认领表就是：100000
下面判断一个用户是否认领某张优惠券
select * from 用户优惠券认领表 where 用户id = '1' and 优惠券id = '2' and 是否认领 = '1'

如果您已经发现了问题，那么下面我就说另外一种设计思路

0x03

我们想想优惠券对于用户认领就两个状态：认领和没有认领，也就是0和1 。
你们估计已经想到我想说什么了。
假如使用一个bit代表一个用户是否认领的状态，那么8bit就能表示8个用户的状态，也就是说一个ascii码就能表示8个用户是否认领的状态.单单在磁盘空间上节省了不少。
那么试试多表查询判断用户是否认领的sql查询:
select 认领bit from 用户优惠券认领表 where 用户id = '1'
现在只需要解析这个认领bit即可.

0x04

那么下面我们来想想这个认领bit怎么设计比较合适
先得知道我们优惠券发放的频率，假如每天发放一个优惠券发放5年：
365 * 1 * 5 = 1825(bit)
也就是1825 / 8 = 228(byte)的长度.

0x05

存储结构弄好了，那么怎么样才能把数据放进去再读出来呢？
上面我们说设计的是1825张优惠券。
那么对于优惠券表就只有1825条记录。
这1825也就对应用户优惠券认领表的1825bit 。
假如我们的优惠券记录表的主键是由1 2 3 4 5 6...1825的方式增加。
那么就有:

     1 % 1825 = 1 
     2 % 1825 = 2
     3 % 1825 = 3
     4 % 1825 = 4
     5 % 1825 = 5
     .
     .
     .
     1824 % 1825 = 1824
     1825 % 1825 = 0

想必大家都看明白了，也就通过取模的方式定位到一个bit的偏移量
基本上这就是在关系型数据库中设计的思路。

0x06

扩展：在数据库中存储和读取二进制毕竟麻烦，根据以上思路，其实我们可以使用redis来解决，就是将优惠券领用的bit据通过redis中setbit和getbit来实现。如果有需要还可以给他一个自动过期时间，是不是更方便？聪明的读者可能已经想到如何解决现实中问题了。

2015-12-27 15:23
by Sean
首发简书